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Introduction 


T  1 

>f  the  major. 


'j'lv 


Abstraction  mappings  are  one  of  the  major,  tools  that  my-colleagues-and-T  use  to  construct 
correctness  proofs  for  concurrent  (including  distributed)  algorithms.  In  this  paper, -Pwill  try  to 
make  one  major  point  about  such  mappings?  that  it  is  useful  to  allow  them  to  be  multivalued. 
That  is,  often  when  one  maps  a  “low-lever  algorithm  L  to  a  ^high-level)*  algorithm  II,  one 
would  like  to  allow  several  states  of  II  to  correspond  to  a  single  state  of  L.  I  believe  that  any 
useful  framework  for  describing  abstraction  mappings  should  include  the  ability  to  describe 
multivalued  mappings,  - -  /  o( 

I  don’t  know  if  this  point  is  especially  controversial.  I  have  been  using  multivalued  mappings 
since  I  started  carrying  out  such  proofs  in  1981,  and  the  popular  notion  of  bisimulation  proposed 
by  Milner  [20]  also  permits  multiple  values  (although  bisimulation  is  a  stronger  notion  than  I 
advocate  here,  since  it  requiies  simulation  lelationships  between  L  and  II  in  both  directions). 


‘This  work  was  supported  by  ONR  contract  N0014-85-K-0168,  by  NSF  contract  CCR-8611442,  and  by 
DARPA  contract  N00014-83-K-0125. 
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However,  work  on  history  variables,  tracing  its  roots  to  [22],  takes  pains  to  avoid  the  use  of 
multivalued  mappings  by  adding  extra  information  to  the  state  of  L,  and  there  are  also  some 
recent  papers  (e.g.,  [13,  12,  1])  that  restrict  the  notion  of  mapping  to  be  single-valued. 

I- will  describe  some  situations  in  which  multivalued  abstraction  mappings  are  useful.  The 
examples  I  consider  involve 

1.  algorithm  optimization, 

2.  distribution,  and 

3.  proving  time  bounds. 

I  will  illustrate  the  first  of  these  situations  m  some  detail,  using  one  familiar  example  (the 
Alternating  Bit  Protocol)  and  two  less  familiar  examples,  just  touch  on  the  second,  and  spend 
the  remaining  time  on  the  third  -  it’s  the  newest  use  I  have  found  •: nd  possibly  the  most 
interesting. 

In  my  work,  abstraction  mapping  seem  most  useful  for  .proving  safety  properties;  although 
I  have  been  involved  in  some  work  that  proves  liveness  properties  using  such  mappings  (e;g., 
[18,  27]),  these  efforts  are  still  somewhat  ad  hoc.  Note  that  timing  properties  are  more  like 
safety  properties  than  like  liveness  properties;  because  of  this,  mappings  are  useful  for  ^proving 
timing  properties  as  well.  In  this  paper,  I  will  restrict  attention  to  safety  and  timing  properties. 


2  A  Formal  Framework 


To  be  concrete,  I  will  describe  the  work  in  terms  of  I/O  automata  [18,  17],  since  that  is  what 
I’ve  actually  used.  The  precise  choice  of  model  is  not  very  important  for  most  of  what  I 
will  discuss  here  (timing  proofs  excepted);  other  state  machine  models  would  probably  do  as 
well.  Here,  I  will  review  the  definition  of  an  I/O  automaton  and  will  give  the  usual  notion  of 
mapping,  called  a  possibilities  mapping,  that  I  use  for  defining  a  correspondence  between  I/O 
automata. 


Recall  that  an  I/O  automaton  consists  of  states,  start  states,  actions  classified  by  a  signature 
as  output,  input  and  internal ,  and  steps,  which  are  (state,  action,  state)  triples.  So  far,  that 
makes  them  rather  ordinary  state  machines.  There  is  a  fifth  component  that  is  not  normally 
relevant  to  my  work  involving  mappings  (but  that  I  will  use  in  the  timing  example):  a  .partition 
of  the  output  and  internal  actions  into  classes  indicating  which  are  under  the  control  of  the 
same  underlying  component  in  the  system  being  modeled  by  the  automaton.  Its  main  purpose 
is  in  describing  fair  executions  of  the  automaton  -  executions  that  allow  each  component  fair 
turns  to  continue  taking  steps.  For  now,  I  will  ignore  this  partition. 

An  extended  step  of  an  automaton  describes  a  state  change  that  can  occur  as  a.result.of  a 
finite  sequence  of  actions. 
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The  important  behavior  of  an  I/O  automaton  is  normally  considered  to  be  its  interaction 
with  its  environment,  in  the  form  of  its  behaviors ,  i.e.,  its  sequences  of  input  and  output  actions 
(more  precisely,  its  fair  sequences).  Problems  to  be  solved  by  I/O  automata  are  specified  as 
sets  of  sequences  of  such  actions,  and  an  automaton  is  said  to  solve  a  problem  if  its  (fair) 
behaviors  are  a  subset  of  the  set  of  problem  sequences. 

Let  L  and  H  be  two  I/O  automata  with  the  same  external  action  signature  (same  inputs 
and  outputs).  Define  a  possibilities  mapping  from  L  to  h  to  be  a  mapping  /  from  states(L) 
to  the  power  set  of  states(ff)  satisfying  the  following  properties. 

1.  For  every  start  state  so  of  L ,  there  is  a  start  state  uq  of  H  such  that  uq  6  /(so)* 

2.  If  s'  is  a  reachable  state  of  L,  u1  6  /(s')  is  a  reachable  state  of  H  and  (s',7r,s)  is  a  step 
of  T,  then  there  is  an  extended  step  («',7,u)  of  H  such  that: 

(a)  7| ext(H)  =  ir\ext(L),  and 

(b)  u  €  /(s). 

The  basic  theorem  about  possibilities  mappings  is: 

Theorem  1  If  there  is  a  possibilities  mapping  from  L  to  H,  then  all  behaviors  of  L  are  also 
behaviors  of  II . 

This  theorem  suggests  how  a  possibilities  mapping  can  be  used  in  proving  safety  prop¬ 
erties  (defined  here  to  be  nonempty,  prefix-closed,  limit-closed  properties  of  external  action 
sequences)  for  an  automaton  L.  For  example,  a  safety  property  P  might  be  specified  as  the 
set  of  behaviors  of  an  automaton  H .  Then  a  possibilities  mapping  from  L  to  H  shows  that 
the  behaviors  of  L  all  satisfy  P.  For  another  example,  it  might  be  possible  to  show  that  the 
behaviors  of  an  automaton  H  all  satisfy  a  safety  property  P;  then  a  possibilities  mapping  from 
L  to  H  shows  that  the  behaviors  of  L  all  satisfy  P. 

Concurrent  systems  are  modeled  by  compositions  of  I/O  automata,  as  defined  in  [18,  17]. 
In  order  to  be  composed,  automata  must  be  strongly  compatible ;  this  means  that  no  action 
can  be  an  output  of  more  than  one  component,  that  input  actions  of  one  component  are  not 
shared  by  any  other  component,  and  that  no  action  is  shared  by  infinitely  many  components. 
The  result  of  such  a  composition  is  another  I/O  automaton. 


3  Algorithm  Optimization 

An  important  use  of  a  possibilities  mapping  is  to  decompose  the  correctness  proof  for  an  “op¬ 
timized”  algorithm  L  using  an  “unoptimized”  variation  II  as  an  intermediate  stage.  Typically, 
H  would  be  a  simple  and  redundant  algorithm  that  is  easy  to  understand  because  it  maintains 
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a  lot  of  intuitively  meaningful  information.  The  algorithm  L  would  be  less  redundant,  more 
efficient,  and  correspondingly  more  difficult  to  understand.  The  behavior  of  L  would  be  very 
similar  to  that  of  H,  but  would  be  determined  on  the  basis  of  less  information.  A  good  way 
to  correspond  the  two  algorithms  is  via  a  multivalued  mapping  from  L  to  II.  The  mapping 
“puts  back”  the  information  that  is  lost  in  “optimizing”  H\  since  there  may  not  be  a  unique 
way  to  do  this,  the  mapping  must  be  multivalued. 

In  this  section,  I  give  three  examples.  The  first  is  a  version  of  the  well-known  Alternating 
Bit  Protocol  [4],  the  second  an  example  from  database  concurrency  control,  and  the  third  an 
example  from  highly  available  replicated  data  management. 

3.1  Alternating  Bit  Protocol 

I  begin  with  the  Alternating  Bit  Protocol  (ABP),  mostly  because  it  is  simple  and  should  be 
familiar  from  other  papers  on  verification.  Although  the  main  interest  in  this  example  is 
normally  the  liveness  properties,  here  I  will  only  consider  safety.  The  key  safety  property -to 
be  proved  is,  roughly  speaking,  that  the  subsequence  of  messages  delivered  is  a  prefix  of  the 
subsequence  sent. 

3.1.1  Problem  Statement 

More  specifically,  I  define  correctness  at  the  external  boundary  of  the  ABP  component  (the 
data  link  boundary).  The  input  actions  are  SEND(m),  where  m£  M,  the  message  alphabet. 
The  output  actions  are  RECEIVE(m),m  €  M.  The  correctness  property  P  is  the-set  of 
sequences  (3  of  SEND  and  RECEIVE  actions  such  that  in  any  prefix  (3'  of  /?,  the-sequence 
of  messages  received  in  /?'  is  a  prefix  of  the  sequence  of  messages  send  in  (3' . 


3.1.2  Architecture 


The  architecture  for  an  implementation  consists  of  a  sender  automaton,  a  receiver  automa¬ 
ton,  and  two  FTFO  physical  channels,  channel!  and  channels.  Channel  1  has  input  actions 
SEN Dl(m,b)  and  output  actions  RECEIVEl(m,b),  where  m  £  M  and  6  is  a  Boolean. 
Channel  has  input  actions  SEN D2(b)  and  output  actions  RECEIVE2(b),  where  b  is  a 
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Boolean.  The  system  is  modeled  by  the  composition  of  these  automata,  with  all  actions  except 
SEND(m )  and  RECEIVER)  hidden. 


The  channels  are  fairly  ordinary  FIFO  queues,  except  that  the  effect  of  a  SEND1  or 
SEND2  action  might  or  might  not  be  to  put  the  data  at  the  end  of  the  queue.  (The  effect  of 
a  RECEIVEl  or  RECEIVE2  is  always  to  remove  it,  however.)  More  specifically,  consider 
channell.  Its  state  is  a  finite  queue  of  pairs  ( m,b ),  where  m  €  M  and  b  is  a  Boolean.  Initially, 
the  queue  is  empty. 

SENDl(m,  b),  m  £  M,  b  a  Boolean 
Effect: 

Either  add  ( m ,  b)  to  the  queue  or  do  nothing. 

RECEIVEl(m,  6),  m  £  M,  b  a  Boolean 
Precondition: 

(m,  b )  is  first  on  the  queue. 

Effect: 

Remove  first  element  from  queue. 


3.1.3  Alternating  Bit  Protocol 

The  ABP  uses  the  following  sender.  It  has  inputs  SEN D(m),m  £  M  and  RECEIVE2(b),b 
a  Boolean,  and  outputs  SENDl(m,b),  m£  M,b  a  Boolean.  Its  state  consists  of  the  following 
components:  QS ,  (for  “sender’s  queue”),  which  holds  a  finite  sequence  of  elements  of  Af, 
initially  empty,  and  FS  (for  “sender’s  flag”),  a  Boolean,  initially  1.  The  actions  are: 

SEND(m),  m  £  M 
Effect: 

Add  m  to  end  of  QS. 
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SENDl(m,  b),  m  G  M,  b  a  Boolean 
Precondition: 

m  is  first  on  QS. 
b  =  FS 

Effect: 

None. 

RECEIVE2(b),ba.  Boolean 
Effect: 

if  b  =  FS  then 

[remove  first  element  (if  any)  from  QS; 
FS  :=  FS  +  1  mod  2] 


The  corresponding  receiver  has  inputs  REC EIVEl(m,  b),m  6  M,  b  a-Boolean,  and  outputs 
RECEIVE(rn),m  6  M  and  SEND2(b),b  a  Boolean.  Its  state  consists  of  the  following 
components.  QR  (for  “receiver’s  queue”),  which  holds  a  finite  sequence  of  elements- of  M, 
initially  empty,  and  PR  (for  “receiver’s  flag”),  a  Boolean,  initially  0.  The  actions  are: 

RECEIVE(m),m  G  M 
Precondition: 

m  is  first  on  QR. 

Effect: 

Remove  first  element  from  QR. 

RECEIVEl(m,  b),  m  €  M,  b  a  Boolean 
Effect: 

lib^FR  then 

[add  m  to  end  of  QR; 

FR  :=  FR+  1  mod  2] 

SEND2(b),b  a  Boolean 
Precondition: 
b  =  FR 

Effect: 

None. 


3.1.4  Redundant  Protocol 

To  prove  the  correctness  of  this  protocol,  I  describe  a  redundant  but  much  easier  to  understand 
variant  of  the  protocol.  In  this  ’  ariant,  both  the  sender  and  receiver  keep  sequences  of  messages 
forever;  furthermore,  they  tag  the  messages  with  positive  integer  sequence  numbers  and  send- 
them  with  those  sequence  numbers.  The  sender  continues  to  send  the  same  message  just  until- 
it  receives  an  acknowledgement  with  that  message’s  tag;  then  it  goes  on  to  t’.e  next  message 
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in  sequence.  The  receiver,  on  the  other  hand,  keeps  acknowledging  the  last  message  it  has 
received,  just  until  it  gets  the  next  message.  It  should  be  easy  to  prove  that  this  works, 
using  invariant  assertions.  Then  the  ABP  can  be  proved  to  correspond  to  this  protocol  via  a 
possibilities  mapping,  and  so  is  correct  as  well. 

More  specifically,  the  redundant  algorithm  uses  a  slight  modification  of  the  channels  used 
by  the  ABP  -  the  only  modification  is  that  integer  tags,  rather  than  Boolean  tags,  are  used. 
The  redundant  algorithm  also  has  the  same  actions  as  the  ABP  (except  that  tag  parameters 
are  now  positive  integers).  Its  sender’s  state  consists  of  the  following  components.  SS  (for 
“sender’s  sequence”),  which  holds  an  array  of  (MU  1)  (where  1  is  a  special  “undefined” 
indicator,  which  is  not  an  element  of  M),  indexed  by  the  positive  integers,  initially  identically 
equal  to  1,  IS  (for  “sender’s  integer”),  a  positive  integer,  initially  1,  and  LS  (for  “last  message 
sent”),  a  nonnegative  integer,  initially  0. 

The  actions  are: 

SEND(m),m  6  M 
Effect: 

LS  :=  LS  +  1 
SS(LS)  :=  m 

SENDl(m,i),m  €  M,i  a  positive  integer 
Precondition: 

SS(i)  =  m. 
i  —  IS 

Effect: 

None. 

RECEIVE2(i),i  a  positive  integer 
Effect: 

if  i  =  IS  then 

IS-.=  IS+  1 


The  corresponding  receiver  has  a  state  consisting  of  the  following  components.  SR  (for 
“receiver’s  sequence”),  which  holds  an  array  of  (Mu  .!.),  indexed  by  the  positive  integers, 
initially  identically  equal  to  J_,  IR  (for  ‘"receiver’s  integer”),  an  integer,  initially  0,  and  LR  (for 
“last  message  received”),  an  integer,  initially  0.  The  actions  are: 

RECEIVE(m),m  €  M 
Precondition: 

m  =  SR(LR-+  1) 

Effect: 

LR  :=  LR+  1. 
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RECEIVEl(m,  i),  m£M,ia  positive  integer 
Effect: 

if  i  =  IR  +  1  then 
fSit(i)  :=  m; 

IR:=  III +lj 

SEND2(i),  i  a  positive  integer 
Precondition: 
i  —  IR 

Effect: 

None. 


It  should  be  very  easy  (if  I  have  not  made  any  stupid  mistakes)  to  show  that  the  resulting 
algorithm  correctly  delivers  messages,  i.e.,  that  the  messages  received  are  a  subsequence  of 
those  sent.  The  actual  ABP  is  somewhat  harder  to  understand  because  it  does  no.t  keep  all 
this  information  explicitly;  it  removes  redundancies.  For  example,  it  does  not  keep  the  complete 
sequences  forever,  but  removes  elements  after  they  are  no  longer  needed.  More  interestingly, 
it  does  not  tag  the  messages  in  the  channels  and  on  the  remaining  queues  with  the  integer 
indices,  but  only  with  bits. 

For  later  use,  I  note  here  some  basic  invariants  about  the  behavior  of  this  redundant 
algorithm.  (Call  this  algorithm  H.) 

Lemma  2  The  following  statements  are  true  about  every  reachable  state  of  H . 

1.  Consider  the  sequence  consisting  of  the  indices  in  channels,  followed  by  IR,  followed  by 
the  indices  in  channell,  followed  by  IS.  The  indices  in  this  sequence  are  nondecreasing; 
furthermore,  the  difference  between  the  first  and  last  index  in  this  sequence  is,  at  most  1. 

2.  If  IS  =  IR,  then  LS  >  IS. 

3.1.5  Possibilities  Mapping  Proof 

Now  let  L  denote  the  ABP.  We  will  show  that  L  is  correct  by  demonstrating  a  possibilities 
mapping  from  L  to  H.  Note  that  such  a  mapping  needs  to  be  multivalued  -  it  must  augment 
the  partial  information  contained  in  each  of  the  two  queues  by  filling  in  all  earlier  messages, 
and  must  fill  in  the  integer  values  of  tags  only  working  from  bits. 

In  particular,  we  say  that  a  state  u  of  H  is  in  f(s)  for  state  s  of  L  provided  that  the 
following  conditions  hold. 

1.  s.QS  is  exactly  the  sequence  of  values  of  u.SS  corresponding  to  indices  in  the  closed 
interval  [ u.IS ,  u.LS]. 
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2.  s.FS  =  u.ISmod2. 

3.  s.QR  is  exactly  the  sequence  of  values  of  u.SR  corresponding  to  indices  in  the  dosed 
interval  [u.LR  +  1  ,u.IR]. 

4.  s.FR=  u.IRmod2. 

5.  Channell  has  the  same  number  of  messages  in  s  and  u.  Moreover,  for  any  j,  if  (m,  i)  is 
the  jth  message  in  channell  in  u ,  then  (ro,i  mod  2)  is  the  jth  message  in  channell  in  s . 

6.  Channel2  has  the  same  number  of  messages  in  s  and  u.  Moreover,  for  any  j,  if  i  is  the 
jth  message  in  channel2  in  u,  then  i  mod  2  is  the  jth  meseage  in  channel2  in  a. 

Theorem  3  /  above  is  a  possibilities  mapping. 


3.1.6  Remarks 

Consider  the  structure  of  the  possibilities  mapping  /  of  this  example.  In  going  from  H  to  L, 
unnecessary  entries  are  garbage-collected,  and  integer  tags  are  condensed  to  their  low-order 
bits.  The  multiple  values  of  the  mapping  /  essentially  “replace”  this  information.  In  this 
example,  the  correspondence  between  L  and  H  can  be  described  in  terms  of  a  mapping  in  the 
opposite  direction  -  a  (single- valued)  projection  from  the  state  of  H  to  that  of  L  that  removes 
information.  Then  /  maps  a  state  s  of  L  to  the  set  of  states  of  H  whose  projections  are  equal 
to  s.  While  this  formulation  suffices  to  describe  many  interesting  examples,  it  does  not  always 
work,  as  will  be  seen  in  some  of  the  subsequent  examples  in  this  paper. 

Halpern  and  Zuck  [10]  outline  a  way  of  organizing  the  proof  of  the  ABP  that  is  similar  to 
the  organization  I  have  described;  their  proofs  are  presented  somewhat  differently,  however, 
using  a  formal  theory  of  knowledge. 


3.2  Transaction  Processing 

With  Michael  Merritt,  Bill  Weihl,  Alan  Fekete  and  Jim  Aspnes  [9,  2],  I  have  done  some  work 
on  describing  and  proving  the  correctness  of  locking-  and  timestamp-based  algorithms  for 
database  concurrency  control  and  recovery.  Some  of  this  work  uses  multivalued  possibilities 
mappings  in  a  way  that  is  similar  to  their  use  for  the  ABP.  That  is,  the  proofs  first  show 
correctness  of  a  simple  and  inefficient  protocol  that  maintains  a  lot  of  extra  information,  and 
then  shows  that  some  particular  protocols  of  interest  implement  the  inefficient  protocol  in  the 
formal  sense  of  possibilities  mappings. 

In  this  work,  the  advantage  we  gain  from  the  mapping  strategy  is  not  only  the  decom¬ 
position  of  the  proofs  of  particular  algorithms;  we  also  gain  an  advantage  in  generality.  The 
high-level  protocol  is  designed  to  work  for  arbitrary  data  types.  The  same  high-level  protocol 
can  be  used  to  prove  the  correctness  of  many  specific  low-level  protocols  that  work  (in  more 
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efficient  ways)  for  particular  data  types  such  as  read-write  objects.  (Halpern  and  Zuck  [1C j  use 
mappings  informally  to  get  a  similar  generality  for  protocols  related  to  the  ABP.) 

Here,  I  will  just  describe  what  we  do  for  locking;  our  treatment  of  timestamps  is  similar. 
We  develop  a  locking  algorithm  for  nested  transactions;  in  this  model,  transactions  can  have 
subtransactions,  and  subtransactions  can  have  further  subtransactions,  and  so  on  until  the 
leaves  of  the  transaction  structure,  which  actually  access  data  objects.  The  transaction  nesting 
structure  is  a  forest;  we  augment  it  with  a  dummy  “root”  transaction  representing  the  “outside 
world”,  so  that  it  becomes  a  tree.  Transactions  can  commit  (relative  to  their  parents)  or  abort, 
and  correctness  is  defined  in  terms  of  serializability  among  each  group  of  siblings. 

Our  high-level  algorithm  allows  objects  of  arbitrary  data  type.  We  describe  this  algorithm 
using  a  separate  program  (automaton)  for  each  data  object.  The  automaton  for  an  object  a: 
does  all  the  processing  involving  x.  It  receives  invocations  of  accesses  to  x  and  decides  on  the 
appropriate  responses  to  make.  It  maintains  locks  for  x,  together  with  any  other  necessary 
information  such  as  temporary  versions.  It  receives  information  about  the  commit  and  abort 
of  transactions,  in  order  to  help  it  decide  on  the  appropriate  responses  (and  in  order  to  help  it 
decide  when  it  can  discard  information  and  how  to  manipulate  locks). 

The  complete  high-level  algorithm  can  be  described  as  the  composition  of  these  object  au¬ 
tomata  with  other  automata,  e.g.,  automata  for  transactions  and  a  message  system  automaton. 
In  [9],  we  prove  the  correctness  of  this  composition,  with  a  fairly  complicated  proof.  However, 
once  we  have  proved  this  correctness  for  our  high-level  algorithm,  we  have  a  much  easier  job 
for  some  data-type-specific  variants,  since  we  can  use  possibilities  mappings.  For  example,  one 
very  popular  kind  of  locking  algorithm  is  read-write  locking.  (In  [9],  we  actually  handle  the 
slightly  different  case  of  read-update  locking  rather  than  read-write  locking;  the  difference  is 
that  write  accesses  are  constrained  only  to  write  the  object  with  a  predefined  value,  whereas 
update  accesses  can  make  arbitrary  changes,  depending  on  the  object’s  prior  value.)  We  can 
describe  read-write  locking  as  a  similar  composition,  but  with  different  object  automata;  in 
particular,  we  can  use  a  read-write  object  automaton  for  each  object  x  instead  of  a  arbitrary 
data  type  object  automaton  for  a:.  The  read-write  object  automaton  for  x  maintains  less  in¬ 
formation  than  the  corresponding  arbitrary  data  type  object  automaton,  but  it  can  be  shown 
to  implement  the  former  in  terms  of  a  possibilities  mapping. 

INVOKE  (T) 

INFORM_COMMn  (T) 
INFORM_ABORT(T) 


RESPONDS,  v) 
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To  be  specific,  the  interface  of  an  object  automaton  for  x  consists  of  input  actions 
INVOI(E(T),  IN  FORM -COMM  IT(T),  and  IN  FORM  .ABORT{T),  and  output  action 
RES  PON  D(T,v).  Invocations  and  responses  are  for  particular  accesses  to  x  (T  locates  the 
access  within  the  transaction  nesting  structure);  informs  are  for  arbitrary  transactions. 

Let  H  denote  the  arbitrary  data  type  automaton  for  x.  It  maintains  “intentions  lists”, 
which  are  sequences  of  operations  (i.e.,  (access, return  value)  pairs),  for  each  transaction  in  the 
entire  nesting  structure,  initially  empty  everywhere.  The  intentions  list  for  T  describes  all  the 
operations  that  are  known  to  have  occurred  at  descendants  of  T,  and  have  committed  up  to 
T  but  not  to  its  parent.  It  operates  as  follows.  (Note:  This  is  an  informal  paraphrase  of  the 
code  in  [9].) 

INVOKE(T) 

Effect: 

Record  the  invocation. 

INFORM -COMM  1T{T) 

Effect: 

intentions(parent(T))  :=  intentions(parent(T))intentions(T) 
intentions(T)  :=  empty 

INFORM.ABORT(T) 

Effect: 

intentions(U)  :=  empty  for  all  descendants  U  of  T 

RESPONDS,  v) 

Precondition: 

T  has  been  invoked  and  not  yet  responded  to. 

(T,v)  commutes  with  every  (T’,v’)  in  intentions(U),  where  U  is  not  an  ancestor  of  T. 
total(T)(T,v)  is  a  correct  behavior  of  the  underlying  serial  data  object  for  x. 

Effect: 

intentions(T)  :=  intentions(T)  (T,v) 


Here,  operations  are  said  to  “commute”,  roughly  speaking,  provided  that  in  any  situation 
in  which  both  can  be  performed,  they  can  be  performed  in  sequence,  in  either  order,  and  the 
result  is  the  same  in  both  cases.)  Also,  total(T)  is  defined  to  be  the  result  of  concatenating 
all  the  intentions  lists  for  ancestors  of  T,  in  order  from  the  root  down.  As  I  said  earlier,  our 
algorithm  based  on  this  object  has  a  somewhat  complicated  proof. 

Note  that  H  maintains  a  good  deal  of  explicit  history  information  in  its  intentions  lists. 
Now  suppose  that  the  underlying  serial  data  object  is  a  read-write  object.  In  this  case,  we 
can  improve  the  efficiency  of  this  algorithm  by  maintaining  more  condensed,  specially-tailored 
data  structures  in  place  of  the  intentions  lists.  Tn  particular,  wp  design  a  read-write  object 
automaton  L  that  keeps  sets  of  read  lockholders  and  write-lockholders,  plus  a  version  of  the 
underlying  serial  object  for  each  write-lockholder.  Initially,  the  root  holds  a  write-lock,  With 
the  start  state  of  the  serial  object  as  the  associated  version.  The  steps  of  L  are  as  follows. 
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INVOI<E{T) 

Effect: 

Record  the  invocation. 

IN  FORM  .COM  M  1T{T) 

Effect: 

if  T  is  a  read-lockholder,  then  read-lockholders  :=  read-lockholders  U {parent(T)}  -  {T} 
if  T  is  a  write-lockholder,  then 

[version(parent(T))  :=  version(T); 

write-lockholders  :=  write-lockholders  U{parent(T)}  —  {T}] 

INFORM-ABORT(T ) 

Effect: 

Remove  all  locks  for  descendants  of  T. 

RESPOND(T,  v),T  a  read 
Precondition: 

T  has  been  invoked  and  not  yet  responded  to. 

All  write-lockholders  are  ancestors  of  T. 

v  is  the  version  associated  with  the  least  ancestor  of  T  that  is  a  write-lockholder. 

Effect: 

read-lockholders  :=  read-lockholders  U{T}. 

RESPOND (T,  v),T  a  write 
Precondition: 

T  has  been  invoked  and  not  yet  responded  to. 

All  read-lockholders  and  write-lockholders  are  ancestors  of  T. 
v  =  “nil” 

Effect: 

write-lockholders  :=  write-lockholders  U{T} 
version(T)  :=  v 


The  correctness  of  the  algorithm  using  L  follows  from  that  of  the  algorithm  using  H  once 
we  demonstrate  a  possibilities  mapping  /  from  L  to  H.  The  mapping  says  the  following 
(paraphrased):  u  €  f(s )  exactly  if 


1.  u  and  s  record  that  the  same  set  of  transactions  has  been  invoked. 

2.  u  and  s  record  that  the  same  set  of  transactions  has  been  responded  to. 

3.  s.read-lockholders  is  exactly  the  set  of  transaction  names  T 
contains  a  read  access. 

4.  s.write-lockholders  is  exactly  the  set  of  transaction  names  T 
contains  a  write  access  (together  with  the  root). 


such  that  u.intentions(T) 
such  that  u.intentions(T) 
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5.  For  every  T,  evaluating  total(T)  in  u  results  in  the  value  version(T’),  where  T*  is  the 
least  ancestor  of  T  in  write-lockholders. 

Although  a  read-write  serial  object  is  a  special  case  of  an  arbitrary  data  type  serial  object, 
note  that  the  read-write  object  automaton  L  is  not  really  a  special  case  of  the  arbitrary 
data  type  object  automaton:  the  data  structures  are  different,  and  /  expresses  a  nontrivial 
correspondence  between  the  different  structures.  However,  the  behaviors  of  the  two  objects 
correspond  very  closely,  as  shown  by  the  fact  that  there  is  a  possibilities  mapping  between 
them.  Note  that  the  mapping  /  is  multivalued,  since  the  summary  version  and  lock-holder 
information  maintained  by  the  read-write  object  automaton  does  not  (in  general;  illow  a  unique 
reconstruction  of  the  intentions  list  information  in  the  arbitrary  data  type  object  automaton. 

For  this  example,  as  for  the  ABP,  the  possibilities  mapping  can  be  described  as  the  inverse 
of  a  projection  mapping  states  of  II  to  states  of  L ,  but  here  that  seems  like  a  bit  of  an 
accident.  For,  the  read-update  objects  described  in  [9]  have  a  similar  description  and  proof, 
but  the  mapping  used  there  can  associate  more  than  one  state  of  L  to  a  state  of  II .  (This  is 
because  the  serial  object  state  produced  by  a  sequence  of  operations  might  not  be  uniquely 
determined.) 

Although  we  have  not  worked  this  out,  it  should  be  possible  to  describe  optimized  variants 
of  our  high-level  algorithm  for  other  specific  data  types  besides  read-write  objects  and  read- 
update  objects.  I  expect  that  such  optimizations  should  also  be  verifiable  using  possibilities 
mappings  to  our  high-level  objects. 

Our  treatment  of  timestamp-based  concurrency  control  algorithms  in  [2]  is  analogous  to  our 
treatment  of  locking.  Namely,  we  first  present  an  algorithm  for  arbitrary  data  types  (based  on 
that  of  Herlihy  [11],  but  extended  to  nested  transactions);  we  present  this  using  an  automaton 
for  each  object.  Then  we  present  the  specially-tailored  algorithm  of  Reed  [23]  for  read-write 
objects;  correctness  of  this  algorithm  is  proved  using  possibilities  mappings  to  the  algorithm 
for  arbitrary  data  types. 


3.3  Garbage  Collection 


With  Paul  Leach,  Liza  Martin  and  Joe  Pato  at  Apollo  Computer,  I  have  made  use  of  multival¬ 
ued  possibilities  mappings  to  design  and  prove  correctness  of  an  algorithm  for  replicated  data 
management.  Again,  the  use  involves  decomposing  the  algorithm  using  a  higher-level  and  less 
efficient  algorithm.  I’ll  just  sketch  the  ideas  very  roughly  and  informally  here. 


The  setting  we  consider  involves  a  replicated  data  management  algorithm  in  which  updates 
to  data  objects  can  be  issued  at  arbitrary  nodes.  We  assume  a  timestamp  mechanism  that 
totally  orders  all  updates  produced  anywhere  in  the  system.  Here  I  assume  for  simplicity  that 
all  the  updates  arc  over  writes.  In  this  setting,  nudes  exchange  information  about  ail  the  updates 
that  have  been  generated,  so  (if  the  network  stays  connected),  all  nodes  eventually  find  out 
about  all  updates.  (Other  transactions,  which  I  will  not  discuss  here,  read  the  data  produced 
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by  this  algorithm  and  take  actions  based  on  it.)  We  assume  that  the  network  is  dynamic,  i.e., 
that  nodes  can  be  added  to  and  removed  from  the  system  during  execution.  The  setting  is 
similar  to  those  considered  in  [6,  24,  8].  In  order  to  determine  whether  an  incoming  update 
should  supersede  an  already-known  update  for  the  same  object,  a  node  must  maintain  some 
timestamp  information  for  known  updates.  Because  it  would  be  inefficient  to  keep  the  complete 
history  of  known  updates,  nodes  summarize  this  history  information  in  a  “checkpoint  state” 
that  contains  summarized  values  (with  associated  timestamps)  for  all  objects.  But  because 
of  the  way  nodes  exchange  information  about  updates,  they  also  maintain  some  incremental 
information;  the  data  maintained  by  each  node  is  thus  a  combination  of  a  checkpoint  state  and 
a  log  of  recent  updates.  The  complete  algorithm  can  be  proved  correct  by  standard  techniques 
(basically,  the  safety  properties  to  be  proved  say  that  each  node  is  as  up-to-date  about  the 
updates  originating  at  each  other  node  as  it  thinks  it  is). 

Now,  the  actual  system  has  another  complication  -  we  would  like  to  garbage  collect  infor¬ 
mation  about  objects  whose  latest  update  is  an  “overwrite(x,nil)”,  i.e.,  a  “delete(x)”.  It  would 
be  nice  not  to  have  to  record  this  update  forever  (with  its  associated  timestamp).  But  it  is 
necessary  to  record  it  for  a  while,  in  order  to  correctly  determine  its  timestamp  ordering  with 
respect  to  incoming  updates  of  x.  We  need  a  criterion  that  tells  us  when  we  may  garbage 
collect  such  information  without  affecting  the  behavior  of  the  algorithm.  It  is  quite  nontrivial 
to  determine  such  a  rule,  especially  in  the  case  we  consider,  where  nodes  can  be  added  or 
removed  during  computation;  e.g.,  one  must  ensure  that  updates  issued  by  newly-added  nodes 
can  never  get  ordered  incorrectly  with  respect  to  the  garbage  collected  updates. 

We  have  designed  an  algorithm,  £,  that  includes  a  local  criterion  that  says  when  it  is 
safe  for  ?  node  to  garbage  collect  a  delete  update.  The  final  algorithm  appears  to  be  fairly 
complicated.  It  turns  out  that  the  best  way  to  understand  it  is  by  means  of  a  possibilities 
mapping  from  L  to  the  original  non-garbage  collected  algorithm,  II.  Starting  with  a  state  s 
of  £,  this  possibilities  mapping  obtains  corresponding  states  of  II  by  adding  in  information 
about  the  missing  updates  in  all  possible  ways  that  are  consistent  with  the  current  remaining 
state.  Of  course,  there  may  be  many  ways  to  add  in  such  information;  thus,  the  mapping  is 
multivalued.  With  this  correspondence,  the  correctness  proof  for  the  algorithm  with  garbage 
collection  seems  fairly  straightforward  (although  it  seemed  to  us  to  be  quite  difficult  otherwise). 

Note  that  unlike  the  two  previous  examples,  this  example  uses  a  correspondence  that  is 
not  expressible  as  a  projection  from  H  to  L  -  here,  several  L  states  could  also  be  related  to 
a  single  II  state.  That  is,  given  a  state  of  the  non-garbage  collected  algorithm,  it  is  possible 
to  choose  the  information  to  garbage  collect  in  many  different  ways.  (Choices  of  updates  to 
garbage  collect  are  made  locally  at  individual  nodes,  and  asynchronously  with  respect  to  the 
choices  made  at  other  nodes.)  Thus,  in  this  case,  the  correspondence  is  multivalued  in  both 
directions. 


14 


3.4  Remarks 


The  idea  of  decomposing  algorithms  using  unoptimized  but  simpler  variants  and  possibilities 
mappings  seems  to  be  a  very  generally  useful  technique.  It  is  useful  for  algorithms  that 
perform  explicit  garbage  collection,  and  also  for  algorithms  such  as  the  ABP,  that  simply  omit 
unused  portions  of  the  simpler  information.  I  think  that  this  idea  can  be  pushed  much  further 
in  the  area  of  distributed  algorithms;  many  clever  and  complicated  algorithms  should  have 
decompositions  using  simpler  variants  containing  extra  information.  Tor  example,  I  wonder 
whether  the  many  complicated  algorithms  for  implementing  atomic  registers  (e.g.,  [25, 15])  can 
be  verified  in  this  way.  It  seems  to  me  that  at  least  Bloom’s  special-case  algorithm  [7]  should 
have  a  nice  proof  in  terms  of  integer  tags  rather  than  bits;  perhaps  a  similar  strategy  will  work 
for  other  atomic  registei  algorithms. 

Note  that  all  the  proofs  I  have  given  in  this  section  could  be  recast  in  terms  of  history  vari¬ 
ables  added  to  the  low-level  algorithms  and  single- valued  rather  than  multivalued  mappings. 
Thus,  although  the  proofs  in  terms  of  multivalued  mappings  seem  more  natural  to  me,  there 
is  no  theorem  that  says  that  multivalued  mappings  are  necessary. 


4  Distribution 

Another  way  that  multivalued  mappings  arise  is  in  describing  algorithm  distribution  rather 
than  optimization.  In  the  setting  I  have  in  mind,  a  centralized  algorithm  H  (one  not  explicitly 
decomposed  into  nodes  and  a  message  system)  is  first  shown  to  solve  the  problem  of  interest.  A 
related  distributed  algorithm  (one  that  is  described  explicitly  as  the  composition  of  a  number 
of  node  automata  and  one  or  several  automata  representing  the  message  system)  L  is  then 
given;  we  want  to  show  that  L  is  correct  by  showing  that  it  implements  H  (that  is,  that  all  its 
behaviors  are  behaviors  of  II). 

The  basic  strategy  is  again  to  define  a  mapping  /  from  states  of  L  to  sets  of  states  of  H. 
However,  in  this  case  it  may  be  helpful  to  define  /  in  terms  of  a  collection  of  “component 
mappings”  /,,  one  for  each  component  of  L.  Thus,  each  node  i  has  an  abstraction  mapping 
that  maps  each  of  its  states  to  a  set  of  states  of  II ,  and  likewise  the  message  system  M ,  (or 
each  separate  message  channel  M,  if  there  are  several)  has  a  mapping  / m  from  its  states  to  a 
set  of  states  of  II . 
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These  component  mappings  have  an  interesting  interpretation  -  e.g.,  the  mapping  /,•  for 
node  i  describes,  in  terms  of  Vs  state,  the  “possible  states”  of  the  centralized  algorithm  H, 
as  far  as  i  can  tell.  Thus,  in  a  sense,  this  mapping  can  be  thought  of  as  giving  the  “local 
knowledge”  that  i  has,  of  the  state  of  the  centralized  algorithm. 

Under  certain  conditions  ([lo,  i4])  these  component  mappings  can  be  “composed”  to  yield 
a  possibilities  mapping  from  each  entire  state  of  L  to  a  set  of  states  of  H,  representing  the 
“possible  states”  of  H ,  as  far  as  any  of  the  components  can  tell.  Formally,  the  value  of  /(s), 
for  a  state  s  of  L,  is  exactly  the  intersection  of  the  values  of  fi(si),  where  s,-  is  component  Vs 
state  in  s.  That  is,  the  states  that  are  possible  for  all  the  components  are  just  those  that  are  in 
the  intersection  of  the  sets  that  are  possible  for  all  the  individual  components.  In  other  words, 
the  intersection  of  the  local  knowledge  of  all  the  components  (including  the  message  system) 
is  the  global  knowledge  of  the  system. 

Note  that  the  mapping  /  might  or  might  not  be  multivalued,  but  the  individual  /,-  almost 
certainly  will  be.  This  is  because  in  a  typical  distributed  system,  no  individual  node  knows 
everything  about  the  global  state. 

This  decomposition  can  sometimes  be  used  to  simplify  algorithm  proofs  (at  least,  it  has 
worked  in  one  substantial  case  I  have  tried).  This  case  again  arises  in  transaction  processing. 
In  [19],  I  describe  a  locking  algorithm  similar  to  the  read-write  locking  algorithm  I  described 
earlier  in  this  paper,  by  first  giving  a  centralized  description.  The  algorithm  H  keeps  global 
information  such  as  the  sets  of  transactions  that  have  been  created,  committed  and  aborted, 
plus  certain  “version  mappings”  that  keep  versions  of  various  objects  on  behalf  of  various 
transactions.  In  the  distributed  algorithm,  each  node  keeps  part  of  this  information:  it  knows 
some  of  the  created,  committed  and  aborted  transactions,  and  some  of  the  versions.  The 
mapping  /,  for  a  node  i  just  adds  in  unspecified  other  transactions  and  versions  to  these  sets, 
in  addition  to  the  ones  locally  known.  I  prove  correctness  of  H  directly,  then  combine  the 
/,  as  described  above  to  get  a  possibilities  mapping  /  and  prove  correctness  of  L  using  this 
mapping. 

More  work  is  needed  to  determine  how  generally  useful  this  proof  structure  is. 


5  Proving  Time  Bounds 

My  final  example  arises  in  my  very  recent  work  (joint  with  Hagit  Attiya)  on  timing-based 
algorithms.  The  idea  is  to  use  multivalued  mappings  for  reasoning  about  upper  and  lower 
bounds  on  time  for  such  algorithms.  Although  this  work  is  still  preliminary,  I  think  that  its 
use  of  multivalued  mappings  is  quite  interesting. 

5.1  Overview 

So  far,  abstraction  mappings  (and  assertional  reasoning  in  general)  have  been  used  primarily 
to  prove  correctness  properties  of  sequential  algorithms  and  synchronous  and  asynchronous 
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concurrent  algorithms.  It  would  also  be  nice  to  use  these  techniques  to  prove  properties  of 
concurrent  algorithms  whose  operation  depends  on  time,  e.g.,  that  have  a  clock  that  ticks  at 
an  approximately  predictable  rate.  Also,  the  kinds  of  properties  usually  proved  using  mappings 
are  “ordinary”  safety  properties;  it  would  also  be  nice  to  use  similar  methods  for  proving  timing 
properties  (upper  and  lower  bounds  on  time)  for  algorithms  that  have  timing  assumptions. 

Here.  I  show  how  abstraction  mappings  can  be  used  to  prove  timing  properties  of  timing- 
dependent  concurrent  algorithms.  I'll  focus  on  a  trivial  example,  an  algorithm  consisting  of  two 
concurrently-operating  components,  which  we  call  a  clock  and  a  manager.  The  clock  ticks  at  an 
approximately  known  rate.  The  manager  monitors  the  clock  ticks,  and  after  a  certain  number 
have  occurred,  it  issues  a  GRANT  (of  a  resource).  It  then  continues  counting  ticks;  whenever 
sufficiently  many  have  occurred  since  the  previous  GRANT  event,  the  manager  issues  another 
GRANT.  We  wish  to  give  a  careful  proof  of  upper  and  lower  bounds  on  the  amount  of  time 
prior  to  the  first  GRANT  event  and  in  between  each  successive  pair  of  GRANT  events. 

In  order  to  state  and  prove  such  results,  we  need  to  extend  the  I/O  automaton  model  to 
incorporate  time  in  the  assumptions  and  in  the  conditions  to  be  proved.  Fortunately,  this  has 
been  done  for  us:  Modugno,  Merritt  and  Tuttle  [21]  define  a  suitable  extension  call  the  timed 
automaton  model.  In  that  model,  an  algorithm  with  timing  assumptions  is  described  as  an 
I/O  automaton  together  with  a  boundmap  (a  construct  used  to  give  a  formal  description  of  the 
timing  assumptions).  This  automaton  and  boundmap  generate  a  set  of  timed  executions  and  a 
corresponding  set  of  timed  behaviors.  We  use  timed  automata  to  define  the  basic  assumptions 
about  the  underlying  system,  to  describe  the  algorithm,  and  to  carry  out  a  correctness  proof. 

In  order  to  carry  out  an  assertional  proof  about  time,  we  need  to  reformulate  some  of 
the  definitions  of  [21]  so  that  information  about  time  is  explicitly  included  in  the  algorithm’s 
state.  In  order  to  include  assumptions  about  time  in  the  state,  we  use  the  construction  given 
in  [3],  of  an  automaton  time(A)  for  a  given  timed  automaton  A.  The  automaton  time(A)  is  an 
ordinary  I/O  automaton  (not  a  timed  automaton)  whose  state  includes  predictive  information 
describing  the  first  and  last  times  at  which  various  basic  events  can  next  occur;  this  information 
is  derived  from  the  given  boundmap.  The  I/O  automaton  time(A)  is  related  to  the  original 
timed  automaton  A  in  that  a  certain  subset  of  the  behaviors  of  time(A)  is  exactly  equal  to  the 
set  of  timed  behaviors  of  A. 

We  also  require  a  formal  way  of  describing  the  timing  requirements  to  be  proved  for  our 
algorithm.  In  order  to  do  this,  we  augment  .4  to  another  I/O  automaton  B  which  we  call  the 
performance  machine  this  time  building  in  predictive  information  about  the  first  and  last  times 
at  which  certain  events  of  interest  (e.g.,  GRANT  events)  can  next  occur.  Then  the  problem 
of  showing  that  the  given  algorithm  satisfies  the  timing  requirements  is  reduced  to  that  of 
showing  that  any  behavior  of  the  automaton  time(A)  is  also  a  behavior  of  B.  We  do  this  by 
exhibiting  a  mapping  from  time(A)  to  B.  This  mapping  turns  out  to  be  multivalued;  in  fact, 
it  is  i  'he  form  of  a  set  of  inequalities! 

In  the  remainder  of  this  section,  I  give  more  details. 
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5.2  Formal  Model 


Here  I  describe  timed  automata  and  the  construction  of  time(A). 


5.2.1  Timed  Automata 

Recall  that  an  I/O  automaton  consists  of  actions ,  states ,  start  states,  steps,  and  a  fifth  compo¬ 
nent  that  is  a  partition  of  the  locally  controlled  (output  and  internal)  actions  into  equivalence 
classes.  The  last  is  generally  used  for  fairness  and  liveness,  and  so  I  have  not  used  it  so  far 
in  this  paper,  but  I  will  need  it  now.  The  partition  groups  actions  together  that  are  to  be 
thought  of  as  under  the  control  of  the  same  underlying  process. 

In  [21],  the  I/O  automaton  model  is  augmented  to  include  timing  properties  as  follows.  A 
timed  automaton  is  an  I/O  automaton  with  an  additional  component  called  a  boundmap.  The 
boundmap  associates  a  closed  interval  of  the  nonnegative  reals  (possibly  including  infinity,  but 
where  the  lower  bound  is  not  infinity  and  the  upper  bound  is  not  0)  with  each  class  in  the 
automaton’s  partition.  This  interval  represents  the  range  of  possible  lengths  of  time  between 
successive  times  when  the  given  class  gets  a  chance  to  perform  an  action.  Let  bt(C)  and  bu(C) 
denote  the  lower  and  upper  bounds,  respectively,  assigned  by  the  boundmap  b  to  class  C. 

Now  I  describe  how  a  timed  automaton  executes.  A  timed  sequence  is  a  sequence  of  alter¬ 
nating  states  and  (action, time)  pairs;  the  times  are  required  to  be  nondecreasing,  and  if  the 
sequence  is  infinite  then  the  times  are  also  required  to  be  unbounded.  Such  a  sequence  is  said 
to  be  a  timed  execution  of  a  timed  automaton  A  provided  that  the  result  of  removing  the  time 
components  is  an  execution  of  the  ordinary  I/O  automaton  underlying  A,  and  the  following 
conditions  hold,  for  each  class  C  of  the  partition  of  A  and  every  i. 

1.  Suppose  bu(C)  ^  oo.  If  some  action  in  C  is  enabled  in  a,-  and  either  i  =  0  or  no  action 
in  C  is  enabled  in  a,_i  or  7 r,-  is  in  C,  then  there  exists  j  >  i  with  t(j)  <  t(i)  +  bu{C)  such 
that  either  nj  is  in  C  or  no  action  of  C  is  enabled  in  aj. 

2.  If  some  action  in  C  is  enabled  in  a;  and  either  i  =  0  or  no  action  in  C  is  enabled  in  o,-_x 
or  7 rt-  is  in  C,  then  there  does  not  exist  j  >  i  with  t(j)  <  t{i )  +  be(C)  and  itj  in  C. 

The  first  condition  says  that,  starting  from  when  an  action  in  C  occurs  or  first  gets  enabled, 
within  time  bu(C)  either  some  action  in  C  occurs  or  there  is  a  point  at  which  no  such  action 
is  enabled.  The  second  condition  says  that,  again  starting  from  when  an  action  in  C  occurs  or 
first  gets  enabled,  no  action  in  C  can  occur  before  time  b((C)  has  elapsed. 

Definitions  for  composition  of  timed  automata  to  yield  another  timed  automaton  are  given 
in  [21].  We  model  real-time  systems  as  compositions  of  timed  automata. 


18 


5.2.2  The  Automaton  time(A) 


Given  any  timed  automaton  A  with  boundinap  6,  we  now  show  how  to  define  the  corresponding 
ordinary  I/O  automaton  time(A).  This  new  automaton  has  the  timing  restrictions  of  A  built 
into  its  state,  in  the  form  of  predictions  about  when  the  next  event  in  each  class  will  occur. 

The  automaton  time(A)  has  actions  of  the  form  (7r,t),  where  t  is  an  action  of  A  and  t  is 
a  nonnegative  real  number.  Each  of  its  states  consists  of  a  state  of  A,  augmented  with  a  time 
called  Ctime  and,  for  each  class  C  of  the  partition,  two  times,  Ftime(C)  and  Ltime(C).  Ctime, 
(the  “current  time”)  represents  the  time  of  the  last  preceding  event,  initially  0.  The  Ftime(C) 
and  Ltime(C )  components  represent,  respectively,  the  first  and  last  times  at  which  an  action 
in  class  C  is  scheduled  to  be  performed  (assuming  it  stays  enabled).  (We  use  record  notation 
to  denote  the  various  components  of  the  state  of  fime(A);  for  instance,  s. automaton. state 
denotes  the  state  of  A  included  in  state  s  of  time(A).)  More  precisely,  each  initial  state 
of  time(A)  consists  of  an  initial  state  s  of  A,  plus  Ctime  =  0,  plus  values  of  Ftime(C ) 
and  Ltime(C)  with  the  following  properties.  If  there  is  an  action  in  C  enabled  in  s,  then 
$.Ftime(C )  =  s.Ctime  +  be(C)  and  Ltime(C)  =  s.Ctime  +  bu(C).  Otherwise,  Ftime(C)  =  0 
and  Ltime(C )  =  oo. 

Others  have  proposed  building  timing  information  into  the  state  (e.g.,  [26]);  our  work  differs 
in  the  particular  choice  of  information  to  use  -  predictive  information,  giving  upper  and  lower 
bounds  for  each  automaton  class. 

The  following  definitions  capture  formally  what  it  means  for  the  given  timing  assumptions 
to  be  respected  by  time(A).  If  (ir,t)  is  an  action  of  time(A),  then  (s',(z,t),s)  is  a  step  of 
time(A)  exactly  if  the  following  conditions  hole 

1.  (s' .automaton-state,  7r ,  s. automaton. state)  is  a  step  of  A. 

2.  s'. Ctime  <  t  =  s.Ctime. 

3.  If  7r  is  a  locally  controlled  action  of  A  in  class  C,  then 

(a)  s'.Ftime  <t<  s'.Ltime. 

(b)  if  some  action  in  C  is  enabled  in  s. automaton. state,  then 
s.Ftime(C)  =  t  +  b((C)  and  s.Ltime(C)  =  t  +  bu(C),  and 

(c)  if  no  action  in  C  is  enabled  in  s. automaton. state,  then  s.Ftime(C )  =  0  and 
s.Ltime(C)  =  oo. 

4.  For  all  classes  D  such  that  7r  is  not  in  class  D, 

(a)  t  <  s'.Ltime(D), 

(b)  if  some  action  in  D  is  enabled  in  s.automaton.state  and  some  action  in  D  is  en¬ 
abled  in  s' .ciutomat on. state  then  s.Ftime(D)  -  s' .Ftime(D)  and  s.Ltime(D)  = 
s' .Ltime(D),  and 


(c)  if  some  action  in  D  is  enabled  in  a. automaton. state  and  no  action  in  D  is  enabled 
in  s'  .automaton. state  then  s.Ftime(D)  =  t  +  bt{D)  and  s.Ltime(D)  =  t  +  bu(D), 
and 

(d)  if  no  action  in  D  is  enabled  in  s. automaton. state,  then  s.Ftime(D)  =s  0  and 
s.Ltime(D)  =  oo. 

Property  3  describes  the  conditions  on  the  particular  class  C  (if  any)  containing  the  action 
•k  -  basically,  that  the  time  for  the  new  action  should  be  in  the  appropriate  interval  for  the 
class.  New  scheduled  times  are  also  set  for  C,  in  case  an  action  in  C  is  enabled  after  this 
step.  Property  4  describes  conditions  involving  each  other  class  D.  The  most  interesting, is 
property  4(a),  which  ensures  that  the  action  in  C  does  not  occur  if  D  has  an  action  that  must 
be  scheduled  first. 

Now  I  state  how  the  behaviors  of  time(A)  are  related  to  the  timed  behaviors  of  A.  Define 
the  complete  executions  of  time(A)  to  be  those  executions  a  of  time(A)  that  satisfy  one  of  the 
following  conditions. 

1.  a  is  infinite  and  the  time  components  of  the  actions  in  a  are  unbounded,  or 

?.  a  is  finite  and  no  locally  controlled  action  of  time(A)  is  enabled  in  the  final  state  of  a. 

The  complete  schedules  and  complete  behaviors  of  time(A)  are  defined  to  be  the  schedules  and 
behaviors,  respectively,  of  complete  executions  of  time(A). 

The  timed  executions  of  a  timed  automaton  A  are  closely  related  to  the  complete  executions 
of  the  corresponding  I/O  automaton  time(A).  In  particular,  what  we  use  is: 

Theorem  4  The  set  of  timed  behaviors  of  A  is  the  same  as  the  set  of  complete  behaviors  of 
time(A). 

This  theorem  implies  that  properties  of  timed  behaviors  of  a  timed  automaton  A  can  be 
proved  by  proving  them  about  the  set  of  complete  behaviors  of  the  corresponding  I/O  au¬ 
tomaton  time(A).  The  latter  task  is  more  amenable  to  treatment  using  assertional  techniques, 
because  of  the  fact  that  timing  information  is  built  into  the  state  of  time(A). 

We  apply  the  time(A)  construction  to  the  timed  automaton  A  modeling  the  entire  system. 


5.2.3  Strong  Possibilities  Mappings 

The  work  in  this  section  requires  a  slightly  strengthened  notion  of  possibiities  mapping  -  one 
that  preserves  the  correspondence  between  all  actions  (internal  as  well  as  external).  Let  L  and 
H  be  automata  with  the  same  actions,  and  let  /  be  a  mapping  from  states  of  L  to  sets  of 
states  of  H.  The  mapping  /  is  a  strong  possibilities  mappings  from  L  to  H  provided  that  the 
following  conditions  hold: 
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1.  For  every  start  state  ;o  of  L ,  there  is  a  start  state  «o  of  H  such  that  tzo  €  /(so)* 

2.  If  s'  is  a  reachable  state  of  .4,  u'  6  f(s')  is  a  reachable  state  of  H ,  and  (s',  r:,  s)  is  a  step 
of  L,  then  there  is  a  step  (u',ir,u)  of  II  such  that  u  €  /(s). 

The  difference  between  this  definition  and  the  ordinary  definition  for  possibilities  mappings 
is  in  the  second  condition,  where  the  actions  are  required  to  correspond  exactly.  Now  recall 
that  the  schedules  of  an  automaton  include  all  its  actions. 

Lemma  5  If  there  is  a  strong  possibilities  mapping  from  L  to  H ,  then  all  schedules  of  L  are 
also  schedules  of  H . 

5.3  The  Algorithm 

The  algorithm  consists  of  two  components,  a  clock  and  a  manager.  The  clock  has  only  one 
action,  the  output  TICK,  which  is  always  enabled,  and  has  no  effect  on  the  clock’s  state.  It 
can  be  described  as  the  particular  one-state  automaton  with  the  following  steps. 

TICK 

Precondition: 

true 

Effect: 

none 


The  boundmap  associates  the  interval  [ci,C2]  with  the  single  class  of  the  partition.  This 
means  that  successive  TICK  events  will  occur  with  intervening  times  in  the  given  interval. 

The  manager  has  input  action  TICK,  output  action  GRANT  and  internal  action  ELSE. 
The  manager  waits  a  particular  number  k  of  clock  ticks  before  issuing  each  GRANT,  count¬ 
ing  from  the  beginning  or  from  the  last  preceding  GRANT.  The  manager’s  state  has  one 
component:  TIMER,  holding  an  integer,  initially  k. 

The  manager’s  algorithm  is  as  follows:  (We  assume  that  k  >  0). 

TICK 

Effect: 

TIMER  :=  TIMER  •  J 

GRANT 

Precondition: 

TIMER  <  0 

Effect: 

TIMER  :=  k 
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ELSE 

Precondition: 

TIMER  >  0 

Effect: 

none 

Notice  that  ELSE  is  enabled  exactly  when  GRANT  is  not  enabled.  The  effect  of  including 
the  ELSE  action  is  to  ensure  that  the  automaton  continues  taking  steps  at  its  own  pace,  at 
approximately  regular  intervals.  Thus,  in  the  situation  we  are  modeling,  when  the  GRANT 
action’s  precondition  becomes  satisfied,  the  action  doesn’t  occur  instantly  -  the  action  waits 
until  the  automaton’s  next  local  step  occurs.  1 

The  partition  groups  the  GRANT  and  ELSE  actions  into  a  single  equivalence  class,  with 
which  the  boundmap  associates  the  interval  [0,/].  We  assume  that  c\  >  l.  2  Now  we  fix  L  to 
be  the  timed  automaton  which  is  the  composition  of  the  clock  and  manager. 

I  now  consider  the  automaton  time(L),  constructed  as  described  in  Section  5.2.  In  this 
case,  the  construction  adds  the  following  components  to  the  state  of  L:  Ctime,  Ftime(TJCK)) 
Ltime(TICK),  Ftime(LOCAL),  and  Ltime(LOCAL).  The  latter  two  represent  the  times  for 
the  partition  class  consisting  of  GRANT  and  ELSE. 

Lemma  6  All  complete  executions  (and  therefore  all  complete  schedules)  of  time(L)  are  infi¬ 
nite. 

This  is  essentially  because  the  clock  keeps  ticking  forever.  This  lemma  tells  us  that  for  this 
example  we  do  not  have  to  worry  about  the  case  where  executions  are  finite  -  we  can  assume 
that  we  have  infinite  executions  in  which  (because  of  the  definition  of  completeness)  the  timing 
component  is  unbounded. 


5.4  The  Performance  Automaton 

We  wish  to  show  that  all  the  timed  behaviors  of  L  satisfy  certain  upper  and  lower  bounds 
on  the  time  for  the  first  GRANT  and  the  time  between  consecutive  pairs  of  GRANT  events. 
More  precisely,  we  wish  to  show  the  following,  for  any  timed  behavior  7  of  B: 

1.  There  are  infinitely  many  GRANT  events  in  7. 

2.  If  t  is  the  time  of  the  first  GRANT  event  in  7,  then  k  ■  ci  <  t  <  k  •  c2  + 1. 

An  alternative  situation  to  model  would  be  an  interrupt-driven  model  in  which  the  action  is  triggered  to 
occur  whenever  its  precondition  becomes  true;  the  action  should  then  occur  shortly  thereafter;  this  situation 
uould  be  modeled  by  omitting  the  ELSE  action.  The  two  automata  have  slightly  different  timing  properties. 
In  this  paper,  I  only  consider  the  first  assumption. 

2 Again,  a  different  assumption  would  change  the  timing  analysis. 
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3.  If  t\  and  ti  are  the  times  of  any  two  consecutive  GRANT  events  in  7,  then 

k  -Ci  —  l  <t2  -  ti  K  k  •  c%  4*  / . 

We  let  P  denote  the  set  of  sequences  of  ( action ,  time )  pairs  satisfying  the  above  three  condi¬ 
tions.  By  the  earlier  characterization,  Theorem  4,  it  suffices  to  show  that  all  complete  behaviors 
of  time(L)  are  in  P. 

I  have  already  shown  how  to  describe  timing  assumptions  by  building  time  information 
into  the  state.  Now  I  show  how  to  give  a  similar  description  for  the  timing  properties  to  be 
proved.  Thus,  we  specify  P  in  terms  of  another  I/O  automaton,  which  we  call  the  performance 
automaton.  Namely,  define  a  new  I/O  automaton  H  by  augmenting  time(L)  with  two  new 
components:  Ftime(GRANT)  and  Ltime(GRANT).  These  are  designed  to  represent  the  first 
and  last  times,  respectively,  that  a  GRANT  event  might  occur.  They  are  maintained  as  follows. 

1.  Initially, 

(a)  Ftime(GRANT)  =  k  •  c  1,  and 

(b)  Ltime(GRANT)  =  k  •  c2  +  /. 

2.  For  each  step  (s',  (GRANT, t),  s )  of  H, 

(a)  s' .Ftime(GRANT)  <  t  <  s' .Ltime(GRANT). 

(b)  s.Ftime(GRANT)  =  t  +  k  •  C\  —  /  and  s.Ltime(GRANT)  =  t  +  k  •  +  /. 

3.  For  each  step  (s',  (n,t),s)  of  H ,  where  n  =  TICK  or  ELSE, 

(a)  t  <  s'.Ltime(GRANT). 

(b)  s.Ltime(GRANT)  =  s'.Ltime( GRANT)  and 

(c)  s.Ftime(GRANT)  =  s' .Ftime(GRANT). 

In  addition,  the  other  components  of  the  state  are  maintained  just  as  in  the  definitions  of 
time(L). 

This  automaton  simply  builds  in  explicitly  the  time  bounds  to  be  proved.  The  initial 
conditions  build  in  the  time  bounds  that  are  supposed  to  hold  for  the  first  GRANT,  and 
condition  2b  builds  in  the  time  bounds  that  are  supposed  to  hold  for  all  the  subsequent  GRANT 
actions.  Conditions  2a  and  3a  ensure  that  nothing  happens  strictly  after  the  latest  time  at 
which  a  GRANT  is  supposed  to  occur.  Condition  2a  also  ensures  that  the  GRANT  does  not 
occur  too  soon. 

The  following  lemma  gives  the  relationship  we  need  between  the  behaviors  of  H  and  the 
condition  P.  (Note  that  the  behaviors  of  II  and  the  sequences  in  P  both  consist  of  elements 
that  are  pairs,  an  action  of  L  together  with  a  time.) 
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Lemma  7  Let  j3  be  an  infinite  schedule  of  H  in  which  the  time  component  is  unbounded.  Then 
beh{fi )  €  P. 

Note  that  the  performance  machine  H  is  a  somewhat  ad  hoc  description  of  the  particular 
timing  properties  to  be  proved  for  our  particular  algorithm.  We  are  currently  working  on 
generalizing  the  treatment  of  performance  machines. 

5.5  Proof 

Now  we  sketch  how  to  prove  'hat  all  timed  behaviors  of  L  are  in  P.  as  needed.  First,  we  show 
that  all  behaviors  of  time(L)  are  also  behaviors  of  the  performance  machine  H ,  using  a  strong 
possibilities  mapping.  Namely,  v.e  define  a  mapping  /  so  that  a  state  u  of  II  is  in  the  image 
set  f(s )  exactly  if  the  following  conditions  hold. 

1.  If  s.TIMER  >  0  then 

(a)  u.Ltime{ GRANT)  >  s.Ltime(TICK)  +  ( s.TIMER  -  l)c2  +  /,  and 

(b)  u.Ftime(GRANT)  <  s.Ftime(TICK)  +  (s.TIMER-  l)Cl. 

2.  If  s.TIM  ER  =  0  then 

(a)  u.ltime(GRANT)  >  s.Ltime(LOCAL),  and 

(b)  u.Ftime(GRANT)  <  s.Ctime. 

Thus,  in  this  case  the  mapping  takes  the  form  of  inequalities  giving  upper  and  lower  bounds 
for  the  time  of  the  next  GRANT  event,  in  terms  of  the  values  of  the  variables  in  the  state  of 
ttme(L).  For  example,  condition  la  says  that  (in  case  the  timer  :»  positive),  the  upper  bound 
that  is  being  proved  on  the  time  for  the  next  GRANT  is  any  value  that  is  at  least  as  great  as 
the  latest  time  for  the  next  TICK,  plus  the  number  of  remaining  TICK  events  that  will  be 
counted  times  the  maximum  time  they  might  take,  plus  the  maximum  time  for  a  local  step. 
This  makes  sense  because  the  quantity  or»  the  right-hand  side  of  the  inequality  is  itself  an  upper 
bound  on  the  time  until  the  next  GRANT ;  if  the  performance  machine  designates  anything  at 
least  as  great  as  tins  expression  as  the  upper  bound  to  be  proved,  then  it  should  be  possible  to 
prove  that  the  algorithm  simulates  the  performance  machine  (i.e.,  that  it  respects  the  upper 
bound  described  by  that  machine). 

Symmetrically,  condition  lb  says  that  (in  case  the  timer  is  positive)  the  lower  bound  that 
is  being  proved  on  the  time  for  the  next  GRANT  is  any  value  that  is  at  most  as  great  as  the 
earliest  time  for  the  next  11  CL  ,  plus  the  number  of  remaining  ticks  that  will  be  counted  times 
the  minimum  time  they  might  take,  (plus  the  minimum  time  for  a  local  step,  which  is  0). 
ihis  makes  sense  because  the  quantity  on  the  right-hand  side  of  the  inequality  is  itself  a  lower 
bound  on  the  time  until  the  next  GRANT',  if  the  performance  machine  designates  anything  at 
most  as  great  as  this  expression  as  the  lower  bound  to  be  proved,  then  it  should  be  possible 
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to  prove  that  the  algorithm  simulates  the  performance  machine  (i.e.,  that  it  respects  the  lower 
bound  described  by  that  machine). 

In  case  the  timer  is  0,  the  upper  bound  that  is  being  proved  on  the  time  for  the  next 
GRANT  is  any  value  that  is  at  least  as  great  as  the  latest  time  for  the  next  local  step.  Again, 
the  quantity  on  the  right-hand  side  of  the  inequality  is  an  upper  bound  on  the  time  until  the 
next  GRANT,  so  that  if  the  performance  machine  designates  anything  at  least  that  large,  it 
should  be  possible  to  prove  that  the  algorithm  simulates  the  performance  machine.  Also  for 
this  case,  the  lower  bound  that  is  being  proved  is  any  value  that  is  at  most  as  great  as  the 
earliest  time  "'or  the  next  local  step,  which  is  the  current  time. 

This  mapping  is  obviously  multivalued,  because  it  is  described  in  terms  of  inequalities.  The 
inequalities  express  the  fact  that  any  sufficiently  large  number  (with  respect  to  the  values  of 
the  variabios  in  the  state  of  time(L))  should  be  provable  as  an  upper  bound  for  the  time  for 
the  next  GRANT,  and  any  sufficiently  small  number  should  be  provable  as  a  lower  bound.  3 
4  We  can  now  show: 

Lemma  8  The  mapping  f  is  a  strong  possibilities  mapping. 

Lemmas  5  and  8  yield  the  following  corollary. 

Corollary  9  All  schedules  of  time(L)  are  schedules  of  H . 

Now  I  can  put  the  pieces  together. 

Theorem  10  All  timed  behaviors  of  L  are  in  P. 

Proof:  Let  7  be  a  timed  behavior  of  L.  Then  by  Theorem  4,  7  is  a  complete  behavior  of 
time(L).  Let  /?  be  a  complete  schedule  of  time(L)  such  that  7  =  beh(0).  By  Lemma  6,  0  is 
infinite,  and  by  the  definition  of  completeness  for  infinite  executions,  the  time  components  of  0 
are  unbounded.  Lemma  9  implies  that  0  is  also  a  schedule  of  H .  Since  0  is  an  infinite  schedule 
of  H  in  which  the  time  components  are  unbounded,  Lemma  7  implies  that  beh(0 )  =  7  is  in  P. 


If  we  simply  replaced  the  inequalities  with  equations,  the  resulting  mapping  would  not  be  a  possibilities 
mapping.  Por  example,  suppose  that  a  clock  tick  occurs  within  less  than  the  maximum  C2.  Then  the  right- 
hand  side  expression  in  la  would  evaluate  after  the  step  to  an  earlier  time  than  before  the  step.  On  the  other 
hand,  the  corresponding  step  in  the  performance  machine  would  not  change  the  value  of  Lhme(GRANT),  the 
correspondence  thus  would  not  be  preserved. 

It  seems  possible  to  use  a  single-valued  mapping  for  this  example  by  complicating  the  definition  of  the 
performance  machine;  however,  since  the  performance  machine  is  serving  as  the  problem  specification,  that 
does  not  seem  like  a  good  idea. 
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Note  that  in  this  case,  the  possibilities  mapping  technique  yields  all  the  correctness  prop¬ 
erties  we  require  -  including  both  safety  and  liveness  properties.  Certain  timing  properties  are 
safety  properties,  e.g.,  lower  bounds,  and  upper  bounds  of  the  form  “if  time  grows  sufficiently 
large,  then  certain  events  must  occur”.  These  can  be  proved  using  possibilities  mappings  in 
much  the  same  way  as  any  other  safety  properties.  But  when  such  conditions  are  combined 
with  the  property  that  all  complete  executions  are  infinite  and  our  assumption  that  the  time  in 
infinite  timed  executions  is  unbounded  (so  that  “time  continues  to  increase  without  bound”), 
they  actually  imply  that  the  events  in  question  must  eventually  occur.  Thus,  liveness  properties 
of  the  kind  that  say  “certain  events  must  occur”  also  follow  from  the  mapping  technique. 


6  Conclusions 

In  this  paper,  I  have  tried  to  illustrate  several  situations  in  which  multivalued  abstraction 
mappings  are  useful  in  algorithm  correctness  proofs.  Multivalued  mappings  are  useful  in  cases 
where  one  algorithm  can  be  described  as  an  optimized  (e.g.,  garbage  collected)  version  of 
another  algorithm,  or  where  a  single  high-level  algorithm  admits  several  specialized  implemen¬ 
tations  tailored  for  different  situations.  They  are  also  useful  in  relating  distributed  algorithms 
to  centralized  variants,  and  in  proving  time  bounds. 

Work  remains  to  be  done  in  exploiting  these  techniques  further.  I  believe  it  will  be  possible 
to  decompose  the  proofs  of  many  other  complicated  concurrent  algorithms  by  expressing  the 
algorithms  as  optimized  versions  of  simpler  algorithms,  or  as  special  cases  of  more  general 
algorithms,  or  as  distributed  versions  of  centralized  algorithms.  It  remains  to  discover  such 
structure  and  express  it  in  terms  of  mappings. 

The  use  of  mappings  for  time  analysis  is  new,  and  should  be  tried  on  more  (and  larger) 
examples.  It  remains  to  see  how  this  technique  combines  with  other  methods  for  time  analysis 
such  as  methods  based  on  bounded  temporal  logic  [5]  or  recurrence  equations  [16].  I  hope  I 
have  made  the  point  I  have  tried  to  make:  that  multivalued  mappings  are  sufficiently  useful 
that  any  useful  formal  framework  incorporating  ab  .  :+ion  mappings  should  permit  them  to 
be  multivalued. 
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A  Proof 


Proof:  By  induction.  For  the  base,  let  s  be  the  start  state  of  L  and  u  the  start  state  of 
H.  First,  s.QS  is  empty.  Also,  [u.JS,  u.LS]  =  [1,0],  which  implies  that  s.QS  is  equal  to  the 
appropriate  (empty)  portion  of  u.SS.  Second,  s.FS  =  1  =  u.ISmod  2.  Third,  s.QR  is  empty, 
and  [u.LR  +  1, u.IR)  =  [1,0],  which  implies  that  s.QR  is  equal  to  the  appropriate  portion  of 
u.SR.  Fourth,  s.FR  =  0  and  u.IR  =  0,  which  is  as  needed.  Fifth  and  sixth,  both  channels  are 
empty. 

Now  show  the  inductive  step.  Suppose  (s',n,s)  is  a  step  of  L  and  u'  G  /(s').  We  consider 
cases  based  on  7r. 

1.  7 r  =  SEND(m) 

Choose  u  to  be  the  unique  state  such  that  (u\n,u)  is  a  step  of  H .  We  must  show  that 
u  G  /(s).  The  only  condition  that  is  affected  by  the  step  is  the  first;  thus,  we  must  show 
that  s.QS  is  exactly  the  sequence  of  values  of  u.SS  corresponding  to  indices  in  the  closed 
interval  [u.IS,u.LS].  But  s.QS  =  s'.QSm.  Since  u'  G  /(s'),  s'.QS  is  just  the  sequence  of 
values  from  u'.SS ,  from  indices  u'.IS  to  u'.LS.  Since  the  step  of  H  increases  LS  by  1  and 
puts  m  in  the  new  position,  we  have  the  needed  equation. 

2.  7T  =  RECEIVER) 

Since  7r  is  enabled  in  s',  m  is  the  first  value  on  s'.QR.  Since  v!  G  /(s'),  m  =  u'  .SR(u'  .LR+ 
1),  which  implies  that  7r  is  enabled  in  u' .  Now  choose  u  to  be  the  unique  state  such  that 
(u',n,u)  is  a  step  of  H.  All  conditions  are  unaffected  except  for  the  third,  that  s.QR 
is  exactly  the  sequence  of  values  of  u.SR  corresponding  to  indices  in  the  closed  interval 
[u.LR+  l,u.IR].  Now,  s.QR  is  the  same  as  s'.QR  with  the  first  element  removed.  Since 
u'  G  /(s'),  we  have  that  s'.QR  is  just  the  sequence  of  values  from  u'.SR,  from  indices 
u'.LR+  1  to  u'.IR.  Since  the  step  of  II  increases  LR  by  1,  we  have  the  needed  equation. 

3.  ir  =  SEN  Dl(m,b) 

Since  7r  is  enabled  in  s',  b  =  s'.FS  and  m  is  the  first  element  on  s'.QS.  Let  i  be  the 
integer  u'.IS.  Since  vl  G  /(s'),  the  first  element  in  s'.QS  is  the  same  as  the  u'.IS  entry 
in  u'.SS ;  that  is,  u'.SS(i )  =  m.  It  follows  that  n  =  SENDl(m,i )  is  enabled  in  «'. 

Now  choose  u  so  that  (u',w,u)  is  a  step  of  H  and  such  that  this  step  puts  a  message 
in  channel  1  exactly  if  the  step  (s',  7 r,s)  does.  We  must  show  that  u  G  /(s).  The  only 
interesting  condition  is  the  fifth;  that  is,  we  must  show  that  channell  has  the  same  number 
of  messages  in  s  and  u.  Moreover,  for  any  j,  if  ( m,k )  is  the  jth  message  in  channell  in 
u,  then  (m,kmod 2)  is  the  jth  message  in  channell  in  s.  The  only  interesting  case  is 
where  both  steps  cause  a  message  to  be  put,  into  the  channel.  Then  the  message  value 
in  both  cases  is  to,  but  the  tag  is  b  for  algorithm  L  and  i  for  H .  It  remains  to  show  that 
b  =  imod2.  But  b  =  s'.FS  and  i  =  u'.IS.  Since  vl  G  /(s'),  we  have  s'  FS  =  u' .ISmod  2, 
which  implies  the  result. 
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k  -  RFC  EIVEl(m,  b) 

S:  ce  /r  it>  enabled  in  s',  (m,b)  is  the  first  element  in  channell  in  s'.  Since  u'  G 
(n  ,  )  is  the  first  element  in  channell  in  u',  for  some  integer  i  with  6  =  imod  2.  Let 
ft  -  ,'ECEIVEl(m,i)\  then  f  is  enabled  in  u'.  Let  u  be  the  unique  state  such  that 
(«‘  v,  '<)  is  a  step  of  H.  We  must  show  that  u  G  f(s). 

All  '•  editions  except  for  the  third,  fourth  and  fifth  are  unchanged.  It  is  easy  to  see 
that  rhe  fifth  is  preserved,  since  each  of  n  and  ft  simply  removes  the  first  message  from 
chan  uell. 

Supjmse  first  that  b  =  s'.FR.  Then  the  effects  of  n  imply  that  the  receiver  state  in  s  is 
ideid':<d  to  that  in  s'.  Now,  since  u'  G  /(s'),  s'.FR  =  u'  .IRmod2\  since  b  =  imod2 ,  this 
case  must  have  i  ^  u'.lR  +  1.  Then  the  effects  of  ft  imply  that  the  receiver  state  in  u  is 
identical  to  that  in  u'.  It  is  immediate  that  the  third  and  fourth  conditions  hold. 

So  now  suppose  that  b  ^  s'.FR.  The  invariant  above  for  II  implies  that  either  i  =  u'.IR 
or  i  =  u'.IR  +  1.  Since  b  =  imod 2  and  (since  u'  G  /(. s'))  s'.FR  =  u'.IRmod 2,  this  case 
must  have  i  =  u'.IR  +  1.  Then  u.IR  =  u’.IR  +  1  and  s.FR  —  s'.FR  +  1  mod  2,  preserving 
the  fourtn  condition.  Also,  u.SR  is  the  same  as  u'.SR  except  that  the  entry  with  index 
u.IR  is  set  equal  to  m;  moreover,  s.QR  is  the  same  as  s'.QR  except  that  m  is  added  to 
the  end.  It  follows  that  the  third  condition  is  preserved. 

5.  7r  =  SEND2(b) 

Since  n  is  enabled  in  s',  b  =  s'.FR.  Let  i  be  the  integer  u'.IR.  Let  f  =  SEND2{i)\ 
clearly,  if  is  enabled  in  u'. 

Now  choose  u  so  that  is  a  step  of  H  and  such  that  this  step  puts  a  message 

in  channel2  exactly  if  the  step  ( s',w,s )  does.  We  must  show  that  u  G  f(s).  The  only 
interesting  condition  is  the  sixth;  that  is,  we  must  show  that  channel2  has  the  same 
number  of  messages  in  s  and  u.  Moreover,  for  any  j,  if  k  is  the  jth  message  in  channel2 
in  u,  then  kmod  2  is  the  jth  message  in  channel2  in  s.  The  only  interesting  case  is  where 
both  steps  cause  a  message  to  be  put  into  the  channel.  Then  the  tag  is  b  for  algorithm 
L  and  i  for  H.  It  remains  to  show  that  b  =  imod  2.  But  b  =  s'.FR  and  i  =  u'.IR.  Since 
u'  G  f(s'),  we  have  s'.FR  =  u'.IRmod  2,  which  implies  the  result. 

6.  7T  =  RECEIVE2(b ) 

Since  7r  is  enabled  in  s',  b  is  the  first  element  in  channel2  in  s'.  Since  u'  G  f(s'),  i  is  the  first 
element  in  channel2  in  u',  for  some  integer  i  with  b  =  imod  2.  Let  f  =  RECEIVE2(i ); 
then  7f  is  enabled  in  u'.  Let  u  be  the  unique  state  such  that  (u',ft,u)  is  a  step  of  H.  We 
must  show  that  u  G  f(s). 

All  conditions  except  for  the  first,  second  and  sixth  are  unchanged.  It  is  easy  to  see 
that  the  sixth  is  preserved,  since  each  of  t.  and  ft  simply  removes  the  first  message  from 
channel2. 

Suppose  first  that  6  ^  s'.FS.  Then  the  effects  of  it  imply  that  the  sender  state  in  s  is 
identical  to  that  in  s'.  Now,  since  u1  G  f(s'),  s'.FS  =  u'.ISmod2;  since  6  =  imod 2, 
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this  case  must  have  i  ^  u'.IS.  Then  the  effects  of  i r  imply  that  the  sender  state  in  u  is 
identical  to  that  in  u' .  It  is  immediate  that  the  first  and  second  conditions  hold  for  this 
situation. 

So  now  suppose  that  b  =  s'.FS.  The  invariant  above  for  H  implies  that  either  i  —  u'.IS— \ 
or  i  =  u'.IS.  Since  b  =  imod 2  and  (since  u'  6  /($'))  s'.FS  =  u'.IS mod2,  this  case  must 
have  i  =  u'.IS.  Then  u.IS  =  u'.IS  +  1  and  $.FS  =  s'.FS  +  1  mod  2,  preserving  the  second 
condition.  Also,  u.SS  is  unchanged;  moreover,  s.QS  is  the  same  as  same  as  s'.QS  except 
that  the  first  entry  (if  any)  is  removed. 

Now,  the  invariant  for  H  and  the  fact  that  the  first  entry  in  channel2  in  u'  has  index  u'.IS 
implies  that  u'.IS  =  u'.IR.  Again  by  the  invariant  for  H,  this  implies  that  u'.LS  >  u'.IS. 
Then  the  fact  that  u'  £  f(s')  implies  that  s'.QS  is  nonempty.  Therefore,  the  first  entry 
in  s'.QS  really  is  removed  by  the  step.  Since  s'.QS  consists  of  the  entries  in  u'.SS,  from 
indices  u'.IS  to  u'.LS,  since  the  first  entry  in  s'.QS  is  removed  to  yield  s.QS  and  since 
u.IS  =  u'.IS  +  1,  it  follows  that  the  first  condition  is  preserved. 
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